A document created using a particular version of a document processing mechanism often cannot be satisfactorily processed by later versions of the document processing mechanism. For example, documents created using a particular version of a word processing application or a spreadsheet application (referred to as “original documents”) often cannot be adequately processed by later versions of these applications. For instance, the original documents may lack information that is needed to fully exploit enhanced functionality provided by the later developed versions of the applications. This can result in the suboptimal rendering of the original documents in the later developed versions of these applications, or in extreme cases, the inability to render any information gleaned from the original documents. And even if the original documents can be displayed, these documents may exhibit suboptimal behavior when processed by later versions of these applications.
Applications developed specifically to render and process markup language documents share the above shortcomings. A typical application includes an Extensible Stylesheet Language (XSL) processor that transforms a document expressed in the Extensible Markup Language (XML) to a document expressed in some presentation-oriented markup language, such as Hypertext Markup Language (HTML). The XSL processor uses a collection of XSL files in transforming XML into HTML, wherein these files effectively specify the appearance of the document as rendered using HTML. The XSL files might have been specifically developed to process particular kinds of XML documents characterized by a specified schema. Subsequently, a developer may have made significant changes in the XSL files to enable processing of new kinds of XML documents having new characteristics, possibly governed by a new schema. Due to these changes, the XSL processor might not be able to satisfactorily process the kinds of XML documents for which it was originally designed. The presentation of the original XML documents using the upgraded XSL files may produce errors, or may be completely proscribed.
FIG. 1 illustrates a conventional strategy for addressing the above-noted problems. FIG. 1 specifically addresses the case of a program-oriented application, such as a word processor (rather than a declarative-oriented rendering mechanism, such as a markup language browser). In this environment, an application program is upgraded from an application version V1 102 to an application version V2 104. Application version V2 104 may include additional functionality compared to application version V1 102, or may omit certain functionality present in the application version V1 102.
In the scenario shown in FIG. 1, a document 106 has been generated by application version V1 102, and it is subsequently desired to process this document 106 using application version V2 104 and render this document 106 on a display device 108. The conventional strategy for handling this task is to provide conversion logic 110. The conversion logic 110 converts the document 106 into a form suitable for processing by application version V2 104 and for presentation on the display device 108. The conversion logic 110 can be implemented as add-on code associated with application version V2 104.
The above strategy has a number of drawbacks. The conversion logic 110 is specifically tailored to translate information produced by application version V1 102 into information expected by application version V2. Hence, the characteristics of the conversion logic 110 are specifically predicated on a detailed comparison between application versions V1 and V2 (102, 104). As such, the conversion logic 110 might not be able to satisfactorily process documents produced by other sources, and it might not be able to process documents in conjunction with other versions of document processing mechanisms. For example, the conversion logic 110 might not be able to process a document produced by some other predecessor version of the application, such as an application version V0.5, etc. Further, the conversion logic 110 may no longer provide satisfactory results for documents 106 produced by application version V1 102 when the application program is upgraded in the future to a later version—say, for example, version V3. In summary, the conversion logic 110 cannot, and was never intended to, handle documents having arbitrary form and content. In other words, the conversion logic 110 is narrowly tailored to the task of translating between applications V1 102 and V2 104. Markup language processors (e.g., browsers) often resort to a similar tactic to that shown in FIG. 1, and therefore suffer from the same shortcomings discussed above.
In the traditional approach, a developer would address these problems by adding modules to the conversion logic 110 to address different permutations in document conversion scenarios. This has drawbacks, because it requires the developers to develop new code each time the processing environment changes.
Based on the foregoing, there is an exemplary need in the art for a more efficient and flexible technique for upgrading documents so that they are compatible with current versions of document processing mechanisms, such as markup language document processing mechanisms.